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Objective 


•  This  presentation  extends  RDAC  architectural 
analysis  down  to  embedded  computing  platforms  and 
up  to  major  programs  of  record.  This  presentation  ties 
together: 

•  Hardware/Firmware  Risk 

•  Software  Risk 

•  Obsolescence  Risk 

•  Management  of  these  risks  via  RDAC 

•  Risk  Management  at  the  Program  of  Record  Level 
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RDAC:  Risk  Management  Framework 


•  RDAC:  Risk  Decision  Authority  Criteria 

•  Originally  created  to  guide  accreditation  of  CDS 
solutions  in  a  Secret  and  Below  Initiative  (SABI) 
environment 

•  Management  of  Residual  Risk 

•  Usage  has  expanded  over  time  to  include  accreditation 
of  System  of  Systems  solutions 

•  Common  Vulnerabilities  found  in  prior  system 
accreditations 

•  Common  Threats  that  challenge  mission  capability 

•  Analysis  that  system  architecture  addresses  the 
vulnerabilities  and  adequately  resists  the  threats 
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Risk  Management 


•  Impossible  technically  and  financially  to  counter  all  known 
risKS 

•  Mitigate  the  known  risks  we  can’t  counter 

•  Understand  the  residual  risk  after  known  risks  are  countered 
or  mitigated 

•  Determine  if  system  architecture  is  sufficiently  robust  with  respect 
to  the  residual  risk 

•  What  about  the  risks  we  don’t  know  or  can’t  anticipate? 

•  Determine  if  system  architecture  is  sufficiently  robust  to  withstand 
additional  risks 

•  Obsolescence  is  a  significant  technical  and  financial  threat 
not  often  addressed  during  original  system  risk  analysis 

•  Obsolescence  events  typically  cost  more  than  the  original 
implementation,  certification,  and  accreditation  combined 
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System  Life  Total  Cost  of  Ownership 


•  Implementation 

•  Certification  /  Accreditation 

•  Deployment 

•  Operations  &  Maintenance 

•  Technology  Refresh 

•  Growing  Attack  Surface  over 
time 

•Obsolescence  Events 


RDAC  Manages  Three  Kinds  of  Risks 


•  Technical  Risk 
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•  Data  Processing  and  Platform  Compromise 

•  Role  and  Network  Exploit 

Data  Risk 

•  Security  Policy  Completenes 

•  Security  Policy  Enforcement 

Attack  Risk 

•  Identity  Threat 

•  Connectivity  Threats 

•  Physical  Threats 

•  Transfer  Threats 
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Additional  Risks  to  be  Managed 


•  Stronger  Adversaries 

•  Increased  capability  of  nation-state  adversaries 

•  Increased  capability  of  sub-national  and  transnational  adversaries 

•  Increased  Attack  Surface 

•  Larger  and  more  complex  systems 

•  Everything  is  connected 

•  Enables  world  wide  remote  adversaries 

•  Mobile  personal  devices  based  on  commodity  software  becoming  the 
warfighter  s  interface  of  choice 

•  Extended  System  Lifetimes 

•  Feature  creep  complication  or  invalidating  original  system  security 
architecture 

•  Reuse  in  unanticipated  environments 

•  Yesterday’s  code  was  not  intended  to  counter  today’s 
threats 
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Obsolescence  Risk 


•  COTS  hardware  platforms  become  unavailable  because  of 
market  influences 

•  COTS  software  platforms  become  unavailable  for  the  same 
reasons 

•  “Murphy”  Obsolescence: 

•  Hardware  and  software  do  not  become  obsolete  at  the  same  time 

•  COTS  hardware  and  software  each  become  obsolete  at  the  worst  possible 
time 

•  The  version  of  COTS  software  that  was  accredited  will  not  run  on  any 
COTS  hardware  you  can  still  buy 

•  Murphy  was  an  optimist: 

•  Ashton  Carter,  USD  AT&L:  “We’re  asking  you  to  do  more  without  more.” 

•  “And  make  it  network-ready” 

•  “And  make  it  Multi-level  Secure” 

•  “And  implement  it  as  a  field  upgrade” 

•  AND  MAKE  IT  HAPPEN  NOW! 
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Using  RDAC  to  Manage  the  Other  Risks 


•  And  also  mitigate  Obsolescence  Risk! 

•  Two  pronged  approach: 

•  Decompose  large  and  complex  security  policies  into  small 
and  simple  independent  components 

•  Sufficiently  large  and/or  complex  policies  may  require  formal 
verification  (more  about  this  later) 

•  Architect  systems  such  that  association  of  data  and  metadata 
is  incorruptible  and  verifiable 


Managing  Development  Risk 


•  Can’t  manage  development  risk  without  understanding 

•  Data  ->  formation  ->  Knowledge  ->  Understanding 

•  Data  ->  formation  (Analysis) 

•  Static  Analysis  of  code,  data  structures,  information  flow,  and  requirements 

•  Coverity,  Code  Sonar,  Code  Surfer,  Understand  of  C++, . . . 

•  University  of  Kentucky  Requirements  Analysis  Tools 

Infomiatioi  ->  Knowledge  (Reduction) 

•  Consistent  interpretation  of  information  and  requirements  across  platforms,  analysts, 
organizations,  and  decision  makers 

•  Metadata  Tagging  (GPS,  TOD,  Mission  Phase,  Classification,  Release-ability)  of  all  data  streams 

•  Architectural  Analysis  Tools  and  consistent  use  of  Data  Dictionary 

•  RDAC,  Architecture  and  Requirements  Analysis 

•  Knowledge  ->  Understanding  (Visualization) 

•  Mitigation  of  Risk  within  Architecture 

•  Minimization  of  total  cost  of  ownership 

•  Affordable  recovery  from  zero-day  defects  and  obsolescence  events 

•  Risk  mitigation  during  development  requires  continuous  review  with 
updated  understanding  of  evolving  risks  and  technology 
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Managing  Operational  Risk 


•  Can’t  manage  operational  risk  without  understanding 

•  Data  ->  ition  ->  Knowledge  ->  Understanding 

•  Data  ->  Information  (Analysis) 

•  Consistent  interpretation  of  information  across  platforms,  analysis, 
organizations,  and  decision  makers 

•  Metadata  associated  with  information  to  give  context,  classification,  and 
release-ability 

•  Information  ->  Knowledge  (Reduction) 

•  Data  and  metadata  organized  so  the  right  questions  can  be  asked 

•  Architectural  analysis  to  discover  accidental  data  and  control  coupling 

•  Knowledge  ->  Understanding  (Visualization) 

•  Actionable  assessments 

•  Risk  mitigation  during  operation  requires  continuous 
monitoring  with  updatea  understanding  of  evolving  risks  and 
technology 


11 


Tools  Enable  Understanding 


•  Can’t  understand  risk  without  tools 

•  Commonly  exploited  vulnerabilities  are  caused  by  tangled 
architectures,  lack  of  standards,  and  common  programming 
flaws 

•  Architecture  Analysis  Tools 

•  Visualize  and  verify  compliance  with  architectural  design 
goals 

•  Static  Analysis  Tools 

•  Verify  correctness  and  standards  compliance  of  code 

•  Dynamic  Analysis  Tools 

•  Verify  correctness  of  concurrency  models 
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Decomposition  of  Large  Complex  Policies 


•  Implement  the  desired  policy  while  simultaneously 
eliminating  possibility  of  internal  inconsistencies 

•  Provide  an  infrastructure  with  three  characteristics 

•  Integrity  of  components  can’t  be  compromised 

•  Information  flow  among  components  is  controlled 

•  Data  is  securely  associated  with  its  metadata  at  its  source 

•  Create  a  flexible  policy  enforcement  framework 

•  React  quickly  to  changes  in  operational  requirements 

•  Adapt  to  obsolescence  events  at  reasonable  cost 
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Association  of  Data  and  Metadata 


•  Cross  domain  guards  no  longer  change  the  sensitivity  of 
data 

•  Redaction  rule  authors  can’t  anticipate  all  use  contexts 

•  Even  perfectly  designed  and  implemented  redaction  is 
vulnerable  to  aggregation 

•  Cross  domain  guards  become  simple  information  flow 
reference  monitors 

•  More  resistant  to  operational  risks  and  obsolescence  risks 
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Planning  for  Assurance 


•  Plan  for  assurance  of  reference  monitors  during  the 
entire  system  life 

•  Systems  evolve  with  each  technical  refresh 

•  Risk  management  strategy  and  assessment  of  that 
strategy  must  also  evolve  in  lock-step  with  the  system 

•  Perform  RDAC  analysis  at  each  stage  of  system  life  to 
prevent  costly  security  shortcomings  later 
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Example  Reference  Monitors 


1 .  CDS:  movement  of  data  and  metadata  between 
domains  based  on  releaseability  policy  for  data  and 
metadata 

a.  Data  and  Metadata  Fusion 

b.  Data  and  Metadata  Extraction 

2.  Encryption:  data  at  rest  (AT),  over  the  air  (IA) 

3.  Metadata  Tagging,  binding  data  to  its  properties 

a.  Mission  Phase,  GPS,  Track,  Time/Date 

b.  Sensor  characteristics 

c.  National  and  classification  markings  of  subject  and  object 

4.  Mapping  of  classification  and  releaseability  markings 
between  nations 
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Reference  Monitor  Characteristics:  NEAT 


•  Non-bypass-able 

•  Information  flows  only  along  the  paths  intended  by  the 
system  designer  and  there  are  no  unintended  paths 

•  Evaluateable 

•  Observes  Principle  of  Least  Privilege  in  all  aspects 

•  Always-invoked 

•  Policy  of  Reference  Monitor  type  is  correctly  enforced  each 
and  every  time  the  reference  monitor  is  invoked 

•  Tamper-proof 

•  Cyber  Hard  infrastructure  and  resource  management 
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Infrastructure  Characteristics:  TIME 


•  Type  safety 

•  Sustain  service  in  the  face  of  faults,  errors,  failures,  hostile,  and 
unforeseen  use  cases 

•  Infiltration 

•  External  subjects  should  NOT  have  influence  over  local 
resources/objects 

•  Mediation 

•  Trusted  subjects  that  have  access  to  multiple  information  flows 
and/or  multiple  critical  functions  should  only  allow  use  of  the 
information  flow  and  critical  functions  by  authorized  subjects 

•  Exfiltration 

•  Internal  subjects  should  NOT  have  influence  over  external 
resources/objects 
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Non-Iterative  Process 


•  When  we  try  to  bolt  on  security  at  the  end 

•  Measures  quality  of  the  system  only  after  everyone 
thinks  the  job  is  done 

•  All  the  time  is  gone 

•  (and  the  system  was  probably  late) 

•  All  the  money  has  been  spent 

•  (and  the  system  was  probably  over  budget) 

•  Obsolescence  events  may  force  C&A  to  start  over 
from  the  very  beginning 
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Non-Iterative  Process 


•  Performing  RDAC  only  during  original  system  C&A  is 
reactive 

•  Even  with  requirement  analysis  traceability  tools 

•  Requirement  satisfaction  analysis  becomes  obsolete  over  time 

•  Even  with  static  analysis  tools 

•  Fixing  this  often  breaks  that 

•  Same  code,  different  platform  forced  by  hardware  obsolescence  can 
make  original  risk  analysis  irrelevant 
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Iterative  Process 


•  Iteratively  using  requirements  traceability  tools  and 
static  analysis  tools  is  proactive 

•  Over  time,  even  innocuous  defects  become  vulnerabilities 

•  Ensures  continual  completeness  of  the  system  security 
solution 

•  Ensure  continual  effectiveness  of  the  solution 

•  Discovers  voids  and  defects  at  the  most  cost  effective  time 

•  Prevents  “Enhancing  this  broke  that  ” 

•  Positive  effect  on  total  system  assurance  over  the  entire 
system  life  cycle 
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Extend  RDAC  Downward  to  Embedded  System 
Components 


•  Embedded  component  specific  system  risks 

•  Increased  hardware  complexity  (i.e.,  multi-core) 

•  Provenance  of  COTS  firmware 

•  OS  evolution  from  bare  metal  to  kernels  to  RTOS  to  Linux 

•  Increased  embedded  system  scope  and  complexity 

•  Applying  RDAC  to  embedded  system  risks 

•  Provenance  of  active  elements 

•  Can  we  trust  that  integrated  memory  controller/PCIE  Bridge/Network 
Interface  chip? 

•  What  do  we  really  know  about  that  TCP  offload  engine? 

•  Global  hardware  and  software  supply  chains 

•  Is  the  original  architecture  still  valid? 

•  Have  new  vulnerabilities  been  introduced? 
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Extend  RDAC  Upward  to  Programs  of  Record 


•  Must  consider  both  operational  risk  and  obsolescence 
risk 

•  Iteratively  performing  risk  analysis  manages 
obsolescence 

•  Reimplementation  is  implementation  at  the  most  expensive 
stage  possible 

•  Flexible  embedded  system  frameworks  and  robust  binding  of 
metadata  enable  adaptation,  extension,  and  interconnection 
instead  of  reimplementation 
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Applying  RDAC  to  Program  of  Record  Risks 


•  Iterative  RDAC  process  during  operation  is  applicable 
to  all  platforms  and  systems 

•  RDAC  should  be  adopted  as  applicable  to  each  platform 
or  system 

•  Within  capabilities  of  current  management  personnel 

•  Adoption  manages  cost  and  schedule  impact  of  obsolescence 
events 

•  Example:  Upgrade  of  a  single  line  of  code  can  require  six  aircraft  for 
six  months  of  retesting  and  can  cost  up  to  $6  million 
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Applying  MILS  /  OSA  to  RDAC 


•  MILS:  Multiple  Independent  Levels  of  Security 

•  OSA:  Open  System  Architecture 

•  MILS /OSA 

•  Leverages  separation,  damage  limitation,  periods  processing, 
and  controlled  information  flow 

•  Isolates  applications  from  technology  and  implementations 

•  Converts  Security  Information  /  Architecture  into  Security 
Awareness  and  Understanding 
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ISO/IEC/IEEE  15026  Assurance  Case 


Attributes 

•  Clear,  Simple 

•  Consistent 

•  Complete 

•  Comprehensible 

•  Defensible 

•  Bounded 

•  Life  Cycle 

•  Testable 

•  Open  Interface 


Dependability 

•  Sustain  service  in 
the  face  of  faults, 
errors,  failures, 
hostile,  and 
unforeseen  use  cases 
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Formal  Validation  and  Verification 
of  Avionics  Systems 


"GWVr2"  is  a  model 
formally  validated 

to  be  a  specification  of 
"Separation" 


Various  Separation  Kernels 
have  been  formally  verified 

against  "GWVr2". 

( 


Separation 

Kernel 


"GWVr2"  was  formally  validated  to  provide  "Separation"  by  formally  demonstrating  that 
an  application  level  Reference  Monitor  that  is  non-bypass-able  and  tamper-proof  can  be 
constructed  on  an  ARINC653  Separation  Kernel.  -  Proof  presented  in  2004  ACL2  workshop. 


Survivability 


Observe 


Act 


Orient 


Decide 


^CONFIDENTIALITY 

o  Critical  Data  PROTECTED 
^INTEGRITY 

o  Free  of  Unauthorized  Manipulation 
S  AUTHENTICATION 

o  Identity  Confirmed 
S  AUTHORIZATION 

o  Privilege  Confirmed 
o  Mutual  Suspicion 
(Reduced  access  based  on 
authentication  uncertainty) 

S  NON-REPUDIATION 

o  Proof  of  Data  Origin  &  Delivery 
S  AVAILABILITY 

o  Critical  functions  READY 
S  SAFETY 

o  Determinism 
o  Reliability 
o  Independence 


Information 

Assurance 


S DESIGNATE  KEY  INFORMATION  EXCHANGES 

o  Standardize  similar  areas  at  Enterprise  level  across  Primes 
o  Blue  force  tracking,  strike,  mission  planning ,  weather, ... 

S MODULARITY  &  VISIBILITY 

o  Design  for  change  and  affordable  technology  refreshes 
o  Minimize  attack  surface 

o  Design  for  recovery  and  adaptation  against  Zero-day  Defects 

S RE-USEABLE  COMPONENTS 

o  Commercial  based  standards  (POSIX,  Open  GL)  -  unmodified 
o  Published  standards  (IEEE  1394,  802.11)  -  unmodified 
o  Established  proprietary  standards  (USB,  Blue  Ray)  -  unmodified 
S INTEROPERABILITY  &  SECURITY  (CJCSI  6212.01E) 
o  Global  Network  Information  Enterprise  Architecture 
o  Support  for  Distributed  degree  of  trust  systems 
S ENABLING  ENVIRONMENTS 

o  Infrastructure  and  Enterprise  API's  Separable 
o  Decouple  data  producers  and  consumers  (cloud  computing) 
o  Register  data  grams  and  data  streams  within  metadata  registry 

•S  DETERRENCE 

o  Undesirable  Consequences 
o  Strength  of  Mechanism 

•S  PREVENTION 

o  Defense  in  Depth 
o  Obfuscation 

S  DETECTION 

o  Visual,  Alarm,  Loss  of  Function,  Attestation 
o  Monitoring 

•S  RESPONSE 

o  Destruction,  Disabling,  Zeroization 
o  Adaption 


Web  Resources 


•  Coding  Standards  and  Practices 

•  http://www.cert.org/secure-coding/scstandards.html 

•  http  ://cwe.  mitre .  or  g/ 

•  National  Vulnerability  Databases 

•  http://web.nvd.nist.gov 

•  http :  //c  ve .  mitre .  or  g/ 

•  DHS  Pocket  Guides  for  Security 

•  https://buildsecurityin.us-cert.gov/swa/pocket  guide  series.html 

•  SEI  Software  Assurance  Curriculum 

•  http://www.sei.cmu.edu/library/abstracts/reports/10tr005.cfm 

•  Risk  Management  Framework 

•  http://csrc.nist.gov/publications/nistpubs/800-37-revl/sp800-37-revl- 

final.pdf 
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